iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 9
2
DevOps

Best Practice for DevOps on GitLab and GCP系列 第 9

Best Practice for DevOps on GitLab and GCP : GitLab 持續整合一定要懂的緩存機制 - Day 9 -

  • 分享至 

  • xImage
  •  

Imgur

前言

延續前兩篇文章,所提到的 cacheartifacts 兩個腳本屬性。兩種屬性都有一個特性,就是會將指定的內容存放在特定的位置。但使用上和用途面是完全不同的,接著我們來看一下他們的差異。

Cache vs Artifacts

| 屬性 | 功能描述 |
| --- | --- | --- |
| Cache | 將 Job 運行過程中的檔案以壓縮方式存放在本地 GitLab Runner 中,供給其他 Job 在後續或他次於此運行時,可以依據 key 來找到先前緩存的檔案,其目的為降低持續整合所需的時間 |
| Artifacts | 將 Job 運行過程中的檔案以壓縮方式存放在遠端 GitLab Server 上,供給給同次不同 Stage 間的 Job 可以獲取先前已產生的緩存檔案,其目的為解決持續整合過程間檔案相依的問題 |

使用建議

Cache

由於每次運行腳本時,Job 預設是隨機指定 GitLab Runner 執行,有高機率無法使用先前所準備的檔案,或是在不同台設備上跑完後,都存放了一份 Cache 導致空間的浪費,建議搭配 Tags 可以指定特定標籤的 Executor,如此就能準確命中緩存的檔案實現加速效果。

Artifacts

作者自己在使用 Artifacts 只有遇到兩個問題。

  1. 早期 GitLab 8.7 左右的版本,對於 expire_in 的標籤沒有正常的支援,會造成檔案在不知何時刪除,或是根本不刪除的困擾,GitLab 9 之後的版本有對這件事修正。

  2. Artifacts 會使用到網路進行傳輸,有機率在伺服器網路平寬不足或伺服器過於忙碌時,導致即便 Retry 數次也失敗的情況,最終造成該次整合測試失敗,建議使用時留意相關的配置。

定期清理

定期清理 Cache 與 Artifacts 是一件重要的事情,尤其是在自建的 GitLab Server 或 Runner 沒有足夠大空間時,這件事情變的尤為重要。

Cache 存放路徑

Executor 類型 預設路徑
Shell 存放在運行 gitlab-runner 服務的使用者加目錄中,參考路徑如下: /home/gitlab- runner/cache/<user>/<project>/<cache-key>/cache.zip
Docker /var/lib/docker/volumes/<volume-id>/_data/<user>/<project>/<cache-key>/cache.zip

Artifacts 存放路徑

Artifacts 預設存放在 /home/git/gitlab/shared/artifacts 目錄中,詳情參考連結

範例

腳本內容

image: docker:stable

stages:
  - build
  - test

job1:
  stage: build
  cache:
    key: "$CI_JOB_NAME-cache"
    paths:
      - cache.txt
  script: 
    - echo "this is cache file" > cache.txt
    - echo "this is artifacts file" > artifacts.txt
    - echo "build, ok"
  artifacts:
    name: "$CI_JOB_NAME-artifacts"
    paths:
      - artifacts.txt
    expire_in: 30 mins

job2:
  stage: test
  script:
    - cat artifacts.txt
    - echo "test, ok"
  dependencies:
    - job1

執行結果

運行第二次的 Pipeline 畫面

Imgur

運行第二次的 Job1 詳細內容

Imgur

運行第二次的 Job2 詳細內容

Imgur

結語

通過範例中的 Job1 詳細內容,可以看到運行第二次時,有獲取到第一次所產生的 Cache。而 Job2 詳細內容中,則可以看到成功獲取到 Job1 所產生的 Artifacts。經過一連串的介紹期望能使讀者在運用到相關功能時,能減少踩雷的機會。

如果嫌 Cache 和 Artifacts 麻煩的讀者,不妨試試存放在遠端的 S3 或其他可以上傳的空間,通過一些命名規則也能自行實現相關的功能,在檔案清理上也會更加的簡潔,缺點大概就是指令會變多,再請自行評估囉。

Reference


上一篇
Best Practice for DevOps on GitLab and GCP : GitLab 之第一次寫腳本就上手 - Day 8 -
下一篇
Best Practice for DevOps on GitLab and GCP : GitLab 淺談單一工具鍊 - Day 10 -
系列文
Best Practice for DevOps on GitLab and GCP30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言